System and method for providing a secure network

ABSTRACT

A method and system for providing a secure network. The system can have a URL programming interface, a server, and a database connected to the server. The server can be configured to receive requests from the URL programming interface. The server can include a file manager, an authentication server, a resource server, and a collaboration server.

TECHNICAL FIELD

The present invention relates to methods and systems to provide securedatabase and network environments having private and public aspects.

BACKGROUND

As digital mobility and geodiversity of workforces increase, contentonce stored locally is often migrated to digital clouds. A commonassumption is that cloud storage is better and cheaper—and by utilizingcloud applications, stakeholder interaction can be more centralized, andtherefore convenient. However, many problems exist with cloudapplications and storage, and conventional wisdom often glosses oversecurity flaws inherent in each.

SUMMARY

The present invention is generally directed to a secure networkecosystems and methods.

An aspect of the secure network ecosystem can include a URL programminginterface, a server, and a database. The server can be configured toreceive a request from the URL programming interface. The server caninclude a file manager, an authentication server, a resource server, anda collaboration server.

In some embodiments, the authentication server can ensures that requestsare valid.

In other embodiments, the secure network ecosystem can further includean application program interface (API). The API can be configured toauthenticate tokens, which can be generated by the authenticationserver. Requests can be HTTP communications and/or FTP communications.

Another aspect of a secure network ecosystem can further include asecond secure network ecosystem. The second secure network ecosystem caninclude a second URL programming interface, a second server, and asecond database. The second database can be connected to the secondserver. The second secure network ecosystem can be configured to sendand/or receive requests from and/or to the secure network ecosystem. Thesecond secure network ecosystem can be configured to send and/or receiveauthentication requests from and/or to the secure network ecosystem.

In yet other embodiments, the second server can determine whetherrequests are authorized based on, for example, a token, which can begenerated by the authentication server. The token can have a limitedlifetime, for example, less than twenty minutes, less than five minutes,less than two minutes.

In some embodiments, the resource server can include a token validator,a query engine, and a metadata manager. The resource server can includea central repository of metadata. The metadata can be publiclyavailable. The metadata can be associated with content. The content canbe publicly unavailable. Filenames associated with the content can bepublicly invisible. In some embodiments, the metadata is publiclysearchable.

In other embodiments, data on the database can be stored according tothe first normal form (1NF), according to the second normal form (2NF),and/or according to the third normal form (3NF). Alternatively, the datacan be stored in violation of one or more of the first, second, andthird normal forms. The database can be a normalized database, anon-normalized database, or a partially non-normalized database.

In yet other embodiments, the database can contain content and/orfilenames associated with the content. The content and/or the filenamescan be encrypted. File extensions associated with the content can beencrypted. The database can further contain public content that isstored as plaintext. Data on the database have locations. The locationscan be obfuscated. The locations can be stored outside of the database.The locations can be hashed.

Other aspects, embodiments, and features will be apparent from thefollowing description, the drawings and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is further described in the detailed descriptionwhich follows, in reference to the noted plurality of drawings by way ofnon-limiting examples of certain embodiments of the present invention,in which like numerals represent like elements throughout the severalviews of the drawings, and wherein:

FIG. 1 illustrates an architectural overview of an embodiment.

FIG. 2 is a diagram of dataflow in an exemplary embodiment.

FIG. 3 illustrates encryption and decryption for an exemplaryembodiment.

FIG. 4 depicts an exemplary embodiment including a PAS.

FIG. 5a illustrates an exemplary dataflow.

FIG. 5b illustrates an exemplary dataflow.

FIG. 5c illustrates an exemplary workflow.

FIG. 6 depicts an exemplary PAS and notification dataflow.

FIG. 7 illustrates an exemplary embodiment implementingecosystem-to-ecosystem chat and messaging.

FIG. 8 illustrates an exemplary embodiment of ecosystem-to-ecosystemcommenting on content.

FIG. 9 illustrates an embodiment for ecosystem-to-ecosystemcollaboration/connection requests.

FIG. 10 depicts exemplary activation process and neighborhoodidentification.

FIG. 11 depicts exemplary activation process and neighborhoodidentification.

FIG. 12 an exemplary file sharing security flowchart.

FIG. 13 illustrates an exemplary window of permissions for differentuser levels.

DETAILED DESCRIPTION

A detailed explanation of the system and method according to exemplaryembodiments of the present invention are described below. Exemplaryembodiments described, shown, and/or disclosed herein are not intendedto limit the claims, but rather, are intended to instruct one ofordinary skill in the art as to various aspects of the invention. Otherembodiments can be practiced and/or implemented without departing fromthe scope and spirit of the claimed invention.

The present invention is generally directed to digital ecosystems,devices and methods for establishing and/or maintaining secure networksthat can have private and public aspects. The various techniques,methods, and systems described herein can be implemented in part or inwhole using computer-based systems and methods. Additionally,computer-based systems and methods can be used to augment or enhance thefunctionality described herein, increase the speed at which thefunctions can be performed, and provide additional features and aspectsas a part of or in addition to those described elsewhere in thisdocument. Various computer-based systems, methods and implementations inaccordance with the described technology are presented below.

A secure network can be embodied by general- or special-purposecomputers and/or servers and can have an internal or external memory forstoring data and programs such as an operating system and one or moreapplication programs. Examples of application programs include computerprograms implementing the techniques described herein, authoringapplications capable of generating documents or other electroniccontent; client applications (e.g., an Internet Service Provider (ISP)client, an e-mail client, and/or an instant messaging (IM) client)capable of communicating with other computer users, accessing variouscomputer resources, and viewing, creating, or otherwise manipulatingelectronic content; and browser applications capable of renderingInternet content and other content formatted according to standards orprotocols such as the Hypertext Transfer Protocol (HTTP). One or more ofthe application programs can be installed on the internal or externalstorage of the general-purpose computer. Alternatively, applicationprograms can be externally stored in or performed by one or moredevice(s) external to the general-purpose computer.

The computers and/or servers can include a central processing unit (CPU)for executing instructions in response to commands, and a communicationdevice for sending and receiving data. One example of the communicationdevice can be a modem. Other examples include a transceiver, acommunication card, a satellite dish, an antenna, a network adapter, orsome other mechanism capable of transmitting and receiving data over acommunications link through a wired or wireless data pathway. Thesystems can also include input/output interfaces that enable wiredand/or wireless connection to various peripheral devices. In oneimplementation, a processor-based system can include main memory and canalso include secondary memory, which can be a tangible computer-readablemedium. The tangible computer-readable medium memory can include, forexample, a hard disk drive or a removable storage drive, a flash basedstorage system or solid-state drive, a floppy disk drive, a magnetictape drive, an optical disk drive (e.g. Blu-Ray, DVD, CD drive),magnetic tape, paper tape, punched cards, standalone RAM disks, IomegaZip drive, etc. The removable storage drive can read from and/or writeto a removable storage medium. A removable storage medium can include afloppy disk, magnetic tape, optical disk (Blu-Ray disc, DVD, CD) amemory card (CompactFlash card, Secure Digital card, Memory Stick),paper data storage (punched card, punched tape), etc., which can beremoved from the storage drive used to perform read and writeoperations. As will be appreciated, the removable storage medium caninclude computer software or data.

In some embodiments, the tangible computer-readable medium memory caninclude other similar means for allowing computer programs or otherinstructions to be loaded into a computer system. Such means caninclude, for example, a removable storage unit and an interface.Examples of such can include a program cartridge and cartridge interface(such as the found in video game devices), a removable memory chip (suchas an EPROM or flash memory) and associated socket, and other removablestorage units and interfaces, which allow software and data to betransferred from the removable storage unit to the computer system.

Aspects can include a network with a knowledgebase and a contentmanagement system (CMS). The CMS and publishing platforms can beutilized to facilitate, e.g., social media, knowledgebase collaboration,curation, public relations, recruitment, sponsorship, and/or marketing.The network can be hosted by one or more servers, such as a Web serverand/or server farm and can provide private and/or public access such asportals and webpages. The server can include file servers and/ordatabase servers, which can be dedicated and/or multiprocessing-typeoperating systems. The server can include mail servers to move and/orstore mail over corporate networks (e.g. via LANs and/or WANs) and/oracross the Internet; web servers to load and serve data across theInternet (e.g. via browsers using HTTP); server platforms that caninclude underlying hardware and/or software to drive the system;application servers that can provide middleware between database serversand end users; real-time communication servers, chat servers, IRCservers, and/or instant messaging (IM) servers that can facilitate thenearly instantaneously exchange of information; File Transfer Protocol(FTP) servers that can facilitate transfer control and/or the securetransfer of files; collaboration servers; list servers; telnet servers;open source servers; and/or virtual servers. Server, as used herein, canrefer to programs that manage resources and/or to physical computersystems. For example, in an embodiment, the server can include a 64-bit,four-core, 2.0 GHz per core (or faster) processor. The server canfurther include 4 GB of RAM for staging and/or 8 GB of RAM forproduction. The server can include a 500 GB drive for staging and a 1 TBdrive for production; but, it would be appreciated by a person havingordinary skill in the art that disk space requirements, as with othercomputer requirements, can vary widely based on user needs andpreferences. In an embodiment, the server can include an operatingsystem such as the 64-bit CentOS; a secure database can comprise anopen-source relational database management system such as MySQL 5.6; andthe web server can be implemented with Apache and utilize PHP. In someembodiments, open ports can include 80, 443, and 8081 (for real-timemessaging).

Tables I and II describe exemplary hardware and software configurationsthat can be utilized for certain embodiments. The tables are intended toprovide context to a person having ordinary skill in the art and are notintended to limit any particular embodiment or invention. A personhaving ordinary skill in the art would appreciate that the exemplaryvalues can be adjusted to meet the needs and preferences associated withimplementation. For example, hard disk space can be dependent upon thequantity and type of content being curated as well as upon the level ofparticipation expected and/or allow for each type of user. Further, thesoftware utilized can be chosen for a particular design preference,project needs, and/or hardware requirements.

TABLE I Exemplary Server Hardware Processor RAM Hard Disk Space PlatformSize 64-bit, 2 cores  8 GB 1 GB to 2 TB per user Small deployment (e.g.100− users) 64-bit, 4 cores 16 GB 1 GB to 2 TB per user Mediumdeployment (e.g. 100-200 users) 64-bit, 8 cores 32 GB 1 GB to 2 TB peruser Large deployment (e.g. 200+ users)

TABLE II Exemplary Server Software Description Value Version OperatingSystem 64-bit Linux, e.g. CentOS, Red Hat, Ubuntu Web Server ApacheVersion 2.4x and above Database MySQL Community Edition 5.x and abovePHP Version 5.6x and above

FIG. 1 illustrates the architecture of an embodiment. Users can sendHTTPS requests via SSL connections from their devices (e.g. laptops,desktops, and/or mobile devices). The requests can be routed forprocessing through an authentication module, where credentials can becompared to those on file, e.g. in a secure database of authorized userinformation which can be on a local operating system or within anauthentication server. Credentials to be authenticated can include thespecific device from which an HTTPS request originated, and if thespecific device is not registered or known, a notification can be sentto the user of attempted accessing by an unknown device. If thecredentials match, the user can be granted authorization for access to afile manager. The file manager can include a module for encrypting filecontent, a file extension manager, and/or a file security wrappermodule. The file manager can control user content and files, and canfurther include managers for file sharing, notifications, messaging,feeds, and/or mail. The file manager can also be in communication withan application database via, e.g., an encryption/decryption manager, adata access manager, and a query builder such as an SQL query builder.The encryption/decryption manager can encrypt and/or decrypt data, suchas sensitive data, and can utilize a purpose-built encryption algorithmand/or a known or publicly available encryption algorithm. The filemanager can further send responses (to a user's initial URL request) viaa cache manager and/or template/HTML manager.

Different encryptions can be utilized in various embodiments. As anexample, a content access key can be encrypted using, e.g., AES-256encryption with a 32-bit key via the mcrypt PHP extension. IDs, whichcan be passed through URLs, can be encrypted using, e.g., normal encodehashing mechanisms with different keys for each module. Each module canbe configured with different key. File content can be encrypted using,e.g., AES-256 encryption with a 32-bit random key via the mcrypt PHPextension. This can be a user-controlled functionality, and can beperformed, e.g., if user selects to encrypt while uploading a content.User passwords can also be hashed using a strong one-way hashingalgorithm (e.g. bcrypt) before storing in database to enhance security.

Database—Hosting and Security

Companies face the increasingly daunting task of communicating vastquantities of knowledge created and shared between employees,stakeholders, customers, decision makers and others. Oftenmulti-institutional, this information can run the gamut from privatefiles to inter-organizational collaboration, to public outreach. Whilesmaller companies might garner savings with public cloud storage due totheir limited needs (i.e., small websites/data stores, low IP concerns,and mostly internal or ad hoc projects), many institutions, especiallylarge ones, typically benefit more from private cloud hybrids. Securityprotocols and data organization should be serious concerns, and mayrequire organization-level physical security and/or regulatoryrequirements to develop and implement best practices.

Embodiments can meet such challenges, offering multiple deploymentoptions to meet an organization's cloud strategy needs. For example, aprivate cloud can be hosted as a standalone, secure cloud database. Aprivate cloud can be hosted through a third-party or on an internal,organization server via cloud applications for existing databases and/orservers. Embodiments can be implemented through a hybrid cloud, e.g. onmultiple servers with a bridge between private and hosted servers, orthrough a hybrid cloud and a public cloud. This flexibility can alloworganizations of different sizes and needs to tailor their cloudstrategy and ramp-up, while coherently addressing security concerns andeffectively managing resources. With flexible designs, multipleimplementation models, and secure, cloud-based, cross-serverfunctionality, embodiments can adapt to evolving enterprise and businessneeds.

The platform can transform data, e.g. through encryption and/orobfuscation, to significantly increase security. Primarily for securityreasons, embodiments can transform and/or obfuscate information atmultiple levels. This can create a labyrinth to thwart a would-be hackerseeking to get information from the system. Additionally, data locationcan be obfuscated such that the database lacks sufficient information tohelp someone determine the location of files for that user within theserver. Preventing the making of connections between a user and theirfiles on a server can make unauthorized data retrieval practicallyimpossible.

To provide further security, the location of data stored outside of thedatabase can also be hashed to make it challenging to determine whichfolders inside the platform correlate to which users. This can beimportant because if it is known where files are stored for a particularuser, it can be possible to retrieve their uploaded documents and otherfiles, for example, through the use of brute force of opening andreading each file.

Additional layers of security can be implemented such as file name andcontent obfuscation and URL link obfuscation. If an unauthorized userwere able to determine the location of certain files on a server, theplatform can provide further obstacles to data breach by hashing thename of each individual folder and file, including the file extension.This can render the task of determining file content impracticablylaborious. URLs that are shown to the users can be virtual URLs suchthat the actual link is not shown. Rather, fake URLs can be shown, andthe actual URLs can be determined in real-time (i.e. on-the-fly) by theapplication. This can occur at the board level and/or the file level.URL obfuscation and/or encryption can eliminate the ability to shareURLs with other users (a security risk and problem with previous systemsthat is often implemented with email and text authorization). Theseadditional layers provide further shields of the actual location of thecontent from the user that can prevent unauthorized users from accessingthe data.

File Management & Storage—Centralized Knowledgebase

Organizations often struggle to utilize clouds and cloud technology asmeans for centralizing information for stakeholders (employees,customers, contractors, investors, etc.). Two types of SaaS models havebeen used for organization of a knowledgebase, specificallycommunication apps (for leveraging project data) and cloud apps (basedon legacy file-storage architecture). Truly effective knowledgebasedesign, however, can leverage a centralized, secure database withdecentralized administration for greater stakeholder participation.Embodiments herein can achieve such goals by utilizing several features.For example, users can collect, collaborate, and annotate files withinthematic folders, creating contextualized resources. Content can haveownership, and file permissions can be set to private, shared withgroups, or published to the public. Content and files can be accessiblevia a central cloud UX. The platform, or app, can be file-type andfile-size agnostic. These features can be considered important butshould also be balanced as user/business preferences dictate to accountfor security and/or increased IT/administrative workload.

File management and storage can further utilizeaggregating/communications models and file storage models. For SaaSproviders employing architectures such as Jive, Yammer, and Slack,content that is accessible within the app is not necessarilycentralized. Instead, the app can rely on simple API calls to servecontent from multiple systems. Although searchable, such apps onlyaddress communication and result in systems or methods that have asocial layer offering only short term productivity (e.g. comments onfiles); search-only contextualization can limit the impact of humanintent and an organization's ability to leverage data; and securitydependencies can be multiplied as other applications are accessed forbasic functionality. Additionally, aggregation-style apps are typicallyorganized within social streams or project files. Both models can beineffective for large scale document sharing and can become silos withinthemselves—e.g., losing a post in a Facebook stream or searching throughgroup emails for relevant files. File storage models (e.g. file sync andshare, or FSS) have been utilized in other cloud apps, such as Box andDropbox. The user experience (UX) merely mimics legacy systems—files areuploaded, folders are nested, and permissions (in enterprise versions)are based upon pre-set roles within the organization. In such familiar,legacy file-storage architecture, files are typically assigned arole-level, and all files beneath that level can be viewed. Thishierarchal remnant of machine-thinking can hamper security efforts andcan be a hindrance in a high-sharing environment. Moreover, IP securitycan be violated when role-based access permissions automatically extendto multiple folders that cannot be severed. Role-based (rather thancontent-based) permissions can be a major contributing factor tolarge-scale data theft. Likewise, file storage apps (and mostaggregator-type apps) often force users to go outside their system toshare files when permission management is untenable. An important aspectin creating a convenient and effective knowledgebase can be theutilization of a blended model, i.e. combining secure databaseintegration, content ownership, and control of user information.

Accordingly, embodiments can be implemented with a blended hosting modelwithout the limitations and security risk associated with other systems.When hosted by a third-party, the application can function as a filestorage model. When used as a bridge between servers ororganizations—or, as part of a cloud ramp-up strategy—the applicationcan mimic the aggregation model. Embodiments can be uniquely qualifiedas a knowledgebase, designed and developed as a social, decentralizedresource library and collaboration platform with secure IP transfer.Familiar social media interface styles and/or features can incorporateuser-profiles and comments, following people, organizations anddepartments, and subscribing to resources and projects. Theknowledgebase can be user-populated; stakeholders can upload content (ifpermitted), edit and create boards, and update metadata and annotations.

Some embodiments include a decentralized system having features such as:admins/sub-admins, who can set user permissions (share, collaborate, orpublish) and can automate administrative review procedures;administration of groups can be assigned to users within theorganization or external collaborators for virtual ecosystems andmulti-stakeholder collaboration; users can manage their own content,from uploading and organizing to annotation and publishing within theirsecurity parameters; organizations can leverage in-house and partnerresources, review workflow and business decisions and efficientlyparticipate in cross-organizational proj ects.

Embodiments can utilize a secure database that has normalized andnon-normalized aspects. The data normalization can involve three basiclevels: First Normal Form (1NF); Second Normal Form (2NF); and ThirdNormal Form (3NF). Database normalization can include 1NF normalizationsuch as the elimination of duplicate columns, separation tables, and theuse of primary keys. The platform generally meets the 2NF databasenormalization requirements, i.e. the use of foreign keys to removeredundant data and storage in separate tables. But, the platform canadvantageously violate this protocol. For example, instead of having onerecord for each curated URL—that each subsequent user shares—each userthat curates a URL can have their own record, even if such a record hasbeen previously added. This can allow the content to be manipulated onthe page (unlike, e.g. Pinterest) as well as the permission scheme tofunction. The platform can be implemented with 3NF normalization, suchas the removal of columns that are not dependent upon primary keys. Forexample, subscribers and likes can be stored in the table for UX andanalytic. This normalization, however, can advantageously be violatedwith regularity to improve performance.

Embodiments can include a CMS for document and/or media management andadditional applications for project management and/or multi-enterprisecollaboration. The CMS can include a centralized repository, auser-curated knowledge base, and a secure external drive alternative.

Any user with authorization can upload files or collect web content tothe centralized repository. Centrally locating resources can reducetransfer costs and avoid administrative bottlenecks. Users create andorganize curations of contextualized data and can add/edit metadata,which can ensure accuracy for local and/or public searching.Administrators can control user-permissions and can allow users tocontrol their own content-permissions for decentralized tasks, such ascollaboration, content/database building, small team review processes,IP transfers, etc.

User-Curated Knowledge Base

Profiles can be searchable. Users can be connected to content theycreate, identifying project ownership, organizational leadership, and/orthe industry focus of the users. Users can connect via social businesstools to thought-leaders, internal/external collaborators, and potentialstakeholders. The platform can also allow subscribing to user content,which in turn can support business collaboration, industry sponsorships,strategic alliances, cross-discipline research, and media-rich learning.Moreover, the platform can be implemented with a familiar and/orintuitive interface, such as a social interface, that can facilitateparticipation, contextualization of complex ideas, and reduceadministrative workload.

Secure External Drive Alternative

To enhance security, embodiments can be installed on an organization'sservers and/or in a privately hosted cloud, negating security concernsover IP transfer through external vendors. Granular, content-levelaccess permissions can be attached to files, rather than individuals,thereby limiting user access to specific content, not levels within adatabase. In some embodiments, content cannot be accessed independently(e.g. by link), and private files can remain within an organization'sknowledgebase by limiting viewing/downloading by user sessioninformation and/or associated permissions.

Additional applications can include secure IP and file transfer, socialbusiness tools, centralized, real-time communications, social mediatools, branded platforms, marketing, and PR asset management. FIG. 2illustrates a diagram of dataflow in an exemplary embodiment. Authorizedusers access the platform from their individual devices. Platform appscan perform authentication and encryption/decryption, as well as accessan application database and user content/files. Encryption anddecryption, depicted in FIG. 3, can include a secure encryption key thatutilizes a plurality of information, such as server system variables,server MAC addresses, secret keys, and/or timestamps.

Peerdash Activation Server

Embodiments can include a Peerdash activation server (PAS), a group oftechnologies that can ensure security for content sharing, collaborationand communication within the ecosystem. PAS can facilitate the sharingof information with users of separate ecosystems, without the need togrant direct access to the server hosting the ecosystem. Allecosystem-to-ecosystem access requests can be managed by PAS, thusallowing users from different ecosystems to cooperate as if theybelonged to one unified system. The core technologies can include one ormore of a PAS authentication server, a PAS resource server, and a PAScollaboration server.

The PAS authentication server can ensure that requests are valid.Requests can take many forms, including performing a search, uploadingmetadata, collaborating, etc. Before a request can be fulfilled, a tokencan be granted from the PAS authentication server. The token can have alimited life to combat hacking and/or spoofing. While the lifetime of atoken's validity can be, e.g., two minutes, fifteen minutes, or as longas desired, the lifetime in a preferred embodiment can be limited to afew minutes or less to enhance security. The token can also be passed toexternal ecosystems, if such a request is made, and that token can alsobe validated through the PAS authentication server prior to passing backany data. The PAS authentication server can be responsible forvalidating any or all requests within the ecosystem.

A PAS resource server can be a central repository of public metadataacross the ecosystem. Public information from each ecosystem (e.g.profiles, boards, content, etc.) can be uploaded periodically to the PASresource server for indexing and/or ranking. This data can be used toreturn relevant search results to users performing searches inside oroutside their ecosystems. The PAS resource server can include a tokenvalidator, a query engine, a metadata manager, and/or anindexing/ranking engine.

FIG. 4 depicts an exemplary embodiment including a PAS. As is shown inthe figure, the X ecosystem includes a non-standard usage of OAuth (2.0)authentication API that does not include private user information, andinstead can reference the PeerID generated on the local level. When an Xecosystem user or invitee requests access to a board and/or content, therequest processor can communicate via the authentication API with thePAS authentication server, which in turn can, if appropriate, generate atoken. The request can then be forwarded to the N ecosystem, andseparately the N ecosystem can communicate with the PAS authenticationserver for token validation purposes. If authorized, the N ecosystem canprocess the request and return an appropriate message and/or content tothe user via the X ecosystem platform. To the X ecosystem user, theentire process is seamless.

FIG. 5a illustrates and describes the exemplary flow of data whensending metadata associated with stored public content to the PAS. FIG.5b illustrates and describes the exemplary flow of data when searchingpublic content hosted by a plurality of ecosystems. FIG. 5c illustratesand describes workflow, with OAuth (2.0), when searching public content.

A PAS collaboration server can be used to facilitate collaborationrequests and/or notifications between ecosystems, as shown in FIG. 6.This can be useful, for example, when User A attempts to collaboratewith User B, and both users belong to different ecosystems. The PAScollaboration server can include a token validator, a connectionprocessor, a notification queue, and a query engine. FIG. 6 depictsadditional exemplary elements of a PAS and data flow duringecosystem-to-ecosystem notification.

Administration

The simplicity required to effectively administer a knowledgebase can bedirectly related to an application's ability to decentralizeadministration and curation, which can increase stakeholderparticipation, reduce administrative bottlenecks, and lower transactioncosts. With some prior apps (such as Dropbox), a dedicated IT manager isrequired for a branded platform. For others (such as Yammer), IT staffis required to manage and maintain supporting apps and databases. Prioraggregated/communications apps generally require additional usertraining due to the difficulties in learning and administering multipleexternal apps. Complexity is increased with role-based permissions(versus content-level permissions tied to identity) as well asengagement costs associated with the ongoing administrative review offiles, connections, and collaborations. Present embodiments can addresssuch problems by providing a centralized CMS with decentralizedadministration, both of which can be scalable. Additional advantages canbe gained from stakeholders sharing responsibilities, fromsub-administrators to user-generated content, including annotating,hash-tagging, and/or contextualizing, etc.

Embodiments can incorporate human design principles in a UX witharchitecture that can facilitation the aggregation of the knowledgebase.Although embodiments can function like a scalable CMS, the platforms canbe designed to mimic social media functionality to achieve simpleusability and administration. A range of content-related permissions canbe employed at each user/owner level. Admins/sub-admins can set userpermissions (share, collaborate, and/or publish) and can automateadministrative review procedures. Administration of groups can beassigned to users within an organization or external collaborators forvirtual ecosystems and multi-stakeholder collaboration. Users can managetheir own content—from uploading and organizing, to annotation andpublishing—within their security parameters. Organizations can leveragein-house and partner resources, review workflow and business decisions,and efficiently participate in cross-organizational projects.Embodiments can facilitate geographically diverse ecosystems, each withdifferent roles and responsibilities, to achieve common goals.Administrators can create sub-administration with one click, givingecosystem partners control over their own stakeholders. The actions ofboth sub-administrators and users can be monitored, e.g., at theadministrative level. Review and approval capabilities for externalcommunications can be handled in real-time (e.g. notification/approvalof individual action) and/or by pre-setting user permission controls fora class of stakeholders. A cross-organizational level of hierarchalcontrol can task users with a broad spectrum of responsibilities.

Embodiments can be configured to facilitate the creation of ecosystems.For example, an administrator can first create an ecosystem. The nameand description of the ecosystem, and if desired a logo, can be chosenand/or uploaded. Users that will be neighborhood admins can be added.Both ecosystem and neighborhood admins can add users, if desired. Addingusers can follow the same process as neighborhood admins, but usersshould not generally be given admin roles. Use permissions can be chosenso as to allow users to upload and/or share (e.g. to social media).Users can be restricted when added. This can be ideal for outsidecollaborators. For example, by allowing upload but not share, suchoutside collaborators can be prevented from speaking for theorganization through social media and/or publish boards. Onceneighborhoods are established, user roles and affiliates can be edited.This feature can be ideal for rotating stakeholders. Profiles can becreated and edited. Profile photo can be directly uploaded and profilefields filled in. Areas of interest/expertise associated with users canbe utilized to increase SEO. A user's social links can be standardized,and internal organizational profile demographics can be include and madeprivate for analytics uses inside the organization.

Users can be given personal user pages. Pop-up menus can be utilized toadd boards, including titles (e.g. having less than 25 letters) anddescription (which can utilize use hashtags for SEO). Boards canoriginate as private and can be changed via permissions. Curate (orcollection) of Web content can be facilitated by drag-and-dropfunctionality, such as a Curate It! button on a tool bar. New Boards canalso be created while curating. Users can upload documents and/or mediato boards. Users can also give upload permission to other users.Subscribe and follow functionality can be incorporated to, e.g., buildlibraries—either for a user's own page or a page that the useradministrates. Subscribed boards can automatically appear in the user'spage, e.g., in a panel under a subscribed tab. Collaborative boards fromother users can also appear under such a Subscribe tab, and alerts tothe user of new content can be generated and sent to the user. Followedpages can appear on the user's page or under a tab as well.

Neighborhood pages can be created. Title and descriptions of the pagecan be included by Admins or authorized users. Admins can use drop downmenus to switch pages for editing and adding announcements. Embodimentscan include collaboration features. For example, to connect to otherusers, a search tab on a user's page can be utilized to go to a userpage and/or to select to connect. Connecting with other users can createa contact list. Buttons can also be incorporated to choose to chat,message, and/or block a user. Board permission settings can be utilizedto invite others to a user's board. Ecosystem publishing can broadcastboards to the entire ecosystem or to specific users. Users can becontrolled from when they are added (e.g. to allow upload but notsharing). Neighborhood admins can then use board permissions to invitecollaborators to upload, while still controlling publishing and sharingabilities. Admins can review boards and content sent to trash by users.This can give Admins the opportunity to avoid data loss. An example ofan admin window showing permissions for different user levels can beseen in FIG. 13.

In some embodiments, board owners can automatically share content thatis public to public media outlets, while a collaborating user can onlyshare to public media outlets with a board owner's permission. Boardscan only be shared to public media by a member of the ecosystem orpublic when boards are set to public. Content within boards that is notpublic can be hidden and not seen by public guests. Content (bothWeb-based and uploaded) that is public can be seen. Embodiments can beconfigured such that only public content that is web-based can be sharedindividually to social media but not uploaded non-private content. If acollaborator is permitted to share at the board level, email sharing canbe made available for individual pieces of web content. Users withpermission can comment, like, and share. This feature can trackworkflow, e.g., on collaborative boards. The system can act as apublishing platform, e.g., when board links are shared via social mediaor email. Guest users can be limited to only seeing collaborativelyshared or public content. Both public and ecosystem users can be allowedto search by multiple variables. A user page can include a panel showingan activity feed. The feed can be controlled by neighborhood adminsand/or comprised of elements including: announcements, created byneighborhood admins; neighborhood activity, which can be an automaticfeed of published boards (ecosystem and/or public); and social mediafeeds, such as a Twitter feed, and can correspond to social media linksgiven for the user's page profile.

Workflow

For both communication and FSS apps, one goal is greater efficiency inworkflow and collaboration. But, while machine interoperability has beenproffered as an adequate replacement of human interact-ability,collaboration has been limited by artificial constraints. When mostpeople think of collaboration, they immediately think of projects andteams—and, while this is a good example, it has limited our way ofthinking about human collaboration. Instead of focusing on how humanswork together on projects (e.g. research, sharing of knowledge,providing input, harnessing human capital), current collaboration appsare only capturing files within projects, and relying on the ability ofsearching to locate them if and when they are needed at latertime—similar to email. The end result is not a human curatedknowledgebase that can be archived and leveraged, but rather looselyaffiliated work product folders.

Embodiments can address these deficiencies by implementing acontent-centric system. For example, all files and folders can bemanipulated, monitored, and/or read for analytics, and interoperabilityvia an API can be mapped. Accordingly, embodiments can foster customergrowth. Analytics need not be a question of what can be read, butrather, what does one wish to know about—e.g. the behavior of users,departments, content, public interaction, etc.—because the content canrecord all transactions. The interoperability of APIs can includeexporting files to social media sites and blogs and connecting tocompeting models (such as Dropbox and/or others). APIs can alsofacilitate more detailed integration, for example due to the contentcentric nature of the system.

File Sharing

When sharing files, an important security concern is how content isshared and accessed. Emphasis has been skewed toward systeminter-operability between database and attendant applications ratherthan human interact-ability between users. In such systems, security ofuser data is balanced against the needs of systems to interoperate. Asmore applications are plugged into such systems, the integrity ofdatabase security is typically weakened.

Certain architectural principles—including role-based access permissionand central login—have been considered best practices. Such premises,however, are based upon legacy file structure systems and need to beexamined for their viability in modern systems such as in cloud-basedsystems. Examples of such principles bear examination or are no longervalid can include: a central OAuth-type system; the convenience versussecurity myth; and two-step verification in transferring files.

Normally, a central login, or OAuth type system, can allow users tosign-in to multiple apps with one user account, e.g. Facebook, and isoften considered necessary for cloud computing. For security consciousorganizations, however, such apps often violate information protocols asall access-based information pertaining to the user is typically storedon the application, including: username and password schemes; specificusernames and affiliated passwords; and file locations andauthorizations. Cloud hosting is often implemented simply as a serversomeone else manages, which means that the security of the data is heldby a third-party—even if hosted as a private instance—which connects allorganizations through a centralized OAuth type system, containing thedecryption keys to all stored data.

Some embodiments overcome this problem by implementing a federated cloudknowledgebase, in which all access information can be held on theorganizations private server/instance, i.e. not on a central app server.This type of decentralized system can require that user names beindependently generated on disparate systems that can be used, but notdecrypted, by a central server.

Another, often minimized, issue of file sharing that arises in thecontext of cloud computing is the convenience versus security myth. MostFSS models are secure only if roles within the organization arehierarchal and clearly delineated. Problems arise when nested filesbecome complex flow charts of information, and secure sharing cannot beachieved within the system. When this happens, administrators are oftentasked with reviewing all folders and documents linked by roles tocollaboration requests, creating administrative bottlenecks andincreasing transaction costs; creating multiple, task-specific foldersand/or duplicating files within limited-sharing folders, resulting innew silos and destroying context; and/or sending documents outside thesystem in an unsecure manner (i.e. two-step verification). Regardless ofwhich ad hoc solution is attempted, both aggregation style and filestorage model cloud apps can break down when information begins toscale. For example, the two-step verification procedure is generallyemployed by all previous file sharing SaaS models. In this model,however, security is sacrificed for convenience. Most previouscloud-based business productivity apps mask serious security problemswithin terms of art, such as risk adjusted. Such protocols revealinherent security flaws that are both a threat to IP and a hurdle toscalability.

Embodiments can include cloud-based collaboration and a contentmanagement platform where access permissions can be directly on thecontent. Both individual files and curated folders (i.e. boards) canhold their own permissions, independent of roles, which can be set bythe user/owner, limited to user permissions set by the administration.Unlike forced hierarchal folder models, content-based permissions cangive both users and organizations greater flexibility in creatingpractical work groups on-the-fly, while reducing administrativebottlenecks.

Traditionally, documents hosted in clouds have been accessible via URLand, as cloud apps developed, linking replaced sending as a means toshare content. Sending a link is not secure. For example, links can becopied, redistributed, and/or stolen. Accordingly, most cloud apps haveimplemented a two-step verification procedure for private sharing. Inmost cases, this involves emailing an allegedly secure link on aseparate channel (e.g. email), and either providing an access key (viaanother channel for security, e.g. text) or setting a time-outmechanism, or both. The myth of the two step verification lies not inthe security of the double handshake itself, but rather in how it isexecuted. The two-step protocol typically tasks users with keeping trackof multiple keys on other systems. But the fundamental nature of asystem utilizing permissions sent externally over emails or texts ordistributing exposed URLs cannot be considered a secure file transfersystem. This also directly affects scalability. For example, on someprevious systems, file hierarchy has required an adherence to a securityprotocol. Using keys to include additional viewers can createadministrative problems that preclude meaningful stakeholder adoption.

Embodiments can be implemented as cloud-based collaboration and contentmanagement platforms that do not require external channels for securecollaboration. In such embodiments, access permissions can be granularand tied to the content so that ideas can stay together. Individualboards and files can be hidden from viewing when a user lacks accesspermission. Two-step authentication can be achieved seamlessly, andusers need not keep track of files, keys, and/or links.

Embodiments can achieve secure IP and file transfer. Permitted users cancreate secure local and network folders that are synced for secure filetransfer. Access permissions can be set and edited by the content owner.Workflow and/or dealflow can be managed by access permissions. Contentcan be organized and maintained as well as can be released all at onceor as relationships or projects develop. Collaborative curations canprovide a secure platform for privately communicating large amounts ofcontextualized content (e.g. reporting, research papers, documentationand media) in industry sponsorships, strategic alliances, andcross-institutional collaboration.

In contrast to the inter-operability model, which approaches userexperience from a machine structured processes, the interact-abilitymodel can utilize a human-centric user experience that is integral (i.e.baked-in) to the design. Embodiments can utilize a central login becausethe unique architecture of certain embodiments does not impose directcontrol on user information. All access and permission information canbe stored on an organization's private server, whether virtual or hostedby the organization itself. User identities can be generated on theorganization's private server/instance.

Accordingly, multiple databases can connect from hosted databases tothose behind security firewalls and to those that require LightweightDirectory Access Protocol (LDAP) or other private identity schemes. Sucharchitecture can be a key feature of a central server providing asecure, federated cloud knowledgebase. Unique user identities can behidden from a central server using multiple, organizational-specific,random encryption techniques. If the first value proposition of thesecure file transfer protocol is the unique PeerID system, the secondcan be content-based permissions.

A file sharing security system can preferably include multiple levels ofsecurity. For example, files can be stored outside a public path,preventing direct access to such files, with the filename outside theapplication. In some embodiments, filenames are nowhere used in theapplication, but instead AccessKeys can be used, which can be randomstrings mapped to the filenames. Each AccessKey can be encrypted, e.g.,using strong AES256 encryption via the mcrypt PHP extension beforepassed to other users. An exemplary file sharing security flowchart isshown in FIG. 12. As shown in the figure, if a user wishes to sharecontent (e.g. a file) by sharing a URL, several security steps can betaken. If the system cannot validate whether the logged in user hasaccess to an access key, the system can generate an error and/or preventaccess.

If a user saves any critical or confidential files in the system, thefile content can also be encrypted using strong AES256 encryption, e.g.,via a mcrypt PHP extension with a dynamic key before storing intoserver. Accordingly, the system can be configured to prevent access evenby system admin or other higher level users. When a user selects toencrypt content during or after uploading, a random key can be generatedand stored with respect to the content. The content can be encryptedwith the random key before storing in server. The system can also beconfigured to generate an error stating that a file in the server iscorrupt if an unauthorized user attempts to open the file in the server.A random/dynamic key can be stored in the secure database, and so aperiodic backup of database may be required.

Communications

Previous business apps generally fall into two classes: social businesstools and file sync and share (FSS) tools. Social media tools generallyfocus on written communications, and content, whether hosted or linked,is typically ancillary. Conversely, FSS systems are designed for contentsharing with limited human interaction beyond direct documentcollaboration. A problem with these two approaches is that reconcilingthe two often requires the interoperability of multiple apps. Suchadditional levels of aggregation (content and communications) usuallyrequire multiple licensing agreements, increases security risks, andinvests the organization in a suite of products that will soon becomeredundant as software moves to the cloud. Embodiments can focus on theinteract-ability of the users, rather than the interoperability ofthird-party feature apps, and can include a full spectrum ofcommunications and content level sharing with the added value ofanticipating organizational needs by allowing creation of auser-generated knowledgebase with minimal oversight that can beleveraged internally to publicly.

Embodiments can include instant messaging (IM) to allow centralized,real-time communications between institutional users and/or authorized,outside collaborators. FIG. 7 illustrates an exemplary embodiment duringecosystem-to-ecosystem chat/messaging. Automatic curation/projectupdating can keep subscribers/collaborators informed and up-to-date, andautomatic alert notifications can be sent upon the addition of curationsand/or changes to projects. Collaborative curations or collaborationproject requests can be handled by authorized users, and need notrequire administration, increasing workflow productivity. FIG. 8illustrates an exemplary embodiment ecosystem-to-ecosystem commenting oncontent.

An effective knowledgebase can include an ability to manage content.Previous FSS and communications apps generally fail to anticipate thefull lifecycle of content management. Present embodiments can implementan effective knowledgebase with increased manageability by facilitatingefficient content discovery. Users can subscribe and/or follow, post tosocial media, and/or use the platform itself for publishing pages withreal-time feeds, SEO, and robust search capabilities. Whether the datais shared between a small group of people, throughout the organization,or publicly, the platform can keep ideas contextualized while granularlevel content permissions can decide who can view, edit, and/or comment.A centralized UX can allow organizations to create searchable, brandedplatforms that can be publicly accessed. Security features inherent tothe architecture allow organizations to invite participation withoutrisking data leaks.

Users authorized by an organization can create a digital library ofresearch, organizations, and people that can be discovered and followedor leveraged by stakeholders of the organization. As a user-createdknowledgebase, users can be tasked with categorizing and/or describing(e.g. editing metadata of) content added to the CMS. Projects andcurations can be published on or by the CMS. Published content can beattributed to its owner, further contextualizing people with ideas thatcan be followed by potential stakeholders. These can ensure that ideasand/or contextualized data can be discovered through searching.Connections can develop into long-term economically beneficialrelationships. Subscribed content can provide the most up-to-dateinformation, fostering sponsorships, and industry cooperation.Collaboration tools can go beyond sharing to foster social media-likeexchange and development of ideas. Privacy settings can allow for thesecure transfer of IP to select individuals. As a central platform withdecentralized tasking, published content can become a media rich libraryfor individuals and/or organizations to socially engage and amplify anorganization's messaging. Further, present technology can reduceengagement costs, maximize institutional HR, and/or amplify humancapital, fostering cross-discipline to interinstitutional collaboration.

Embodiments can be customized to serve an organization's mission. FIG. 9illustrates an embodiment that includes ecosystem-to-ecosystemcollaboration/connection requests. Private collaboration and knowledgetransfer can foster cross-institutional research, resource sharing, andcommercialization by-and-between individuals, groups, organizations,partnerships, and/or institutions. Embodiments can be searchable formedia-rich knowledgebase of resources, and messaging can be amplified,including recruitment, news, and/or initiatives.

Project access permissions can allow sharing to a limited number ofcontacts, inter- to cross-institutionally, or even publicly. This can beused as a means to educate and/or inform. Embodiments can autonomouslybuild timelines of collaboration projects and/or allow users to generatetimelines. The platform can allow invited users from within or outsidethe organization to comment and upload files to group projects,creating, e.g., a record of business decisions. Authorized users cancreate informative and/or training presentations with drag-and-dropfunctionality. Presentations can be shared within groups forcollaboration or published globally, e.g., for SEO purposes.

User pages can include institution branding. Administrative controls candecide the publishing rights of individual users or groups of users. Insome embodiments, all private content can only be shared public mediaoutlets by the owner of the content (provided user is allowed). In someembodiments, public content can be shared by any user and/or the publicat large, amplifying social media efforts. A user's public content canbe optimized for SEO by the user, increasing searchability of content.Content can be subscribed to—and leveraged for social media—by anorganization on its public page, reducing marketing/administrativeworkload.

Large media files and documents can be uploaded into marketing and salesrepositories. Content can be updated for up-to-date, easily accessiblematerials. Organizations can leverage the organized, contextualizedinformation, and the knowledgebase, to create press kits, recruitmentpages, newsletters, etc. A searchable secure database can also allowquick reactions and responses to current events, with existing orautomatically updated content, aggregated by users or stakeholders.

The knowledgebase and content management system can increasecooperation, foster collaboration, by and between organizations andpeople. Multi-level and/or multi-institutional involvement can beachieved with a centralized repository that can be accessed by manystakeholders, in many institutions. Additional collaboration andpublishing tools can also be included, as well as security designed forstoring and/or transferring IP files. Many organizations, however, canbe challenged by resource and administrative shortages. Presentembodiments can effectively marshal cross-institutional resources by,e.g., including democratic, or decentralized, functionality. Forexample, embodiments can include a privately installed, branded platformfor ecosystem management, interinstitutional collaboration, and/oramplification of stakeholder collaboration. The embodiment can include acentralized knowledgebase, CMS, secure access permissions, and/or socialtechnology for intra- to inter-organizational knowledge transfer, filemanagement, and/or social publishing.

Whereas prior inter-enterprise technologies can limit participation andput stresses on administrative workload, present embodiments can allowusers to curate (e.g. collect and organize files, media and web pages)complex ideas, such as research or due diligence and/or to createcollaborative projects with social work-flow that can provide a clearrecord of decision-making for group projects, research, and teams withinor across multiple organizations. Present embodiments can be implementedto enhance security and IP protections. For example, systems can beinstalled on an organization's servers, negating external vendorsecurity concerns. Access permissions can reside on the content level,and access to files through independent URLs can be prevented. In apreferred embodiment, all user files, curations, slides, and projectscan be private by default, but also can be shared selectively,collaboratively, and/or publicly as desired by users and/oradministrators. Selective sharing can include secure knowledge/IPtransfer via platform controls utilizing granular-level IP protection.As an example, authorized users can create their own synchronized filestorage space (e.g. a Dropbox-like folder) for secure file transfer andindividual and/or group review. Collaborative sharing can include secureplatforms for privately communicating among a group or organizationlarge amounts of contextualized content, such as reporting, research,documentation and/or media for industry sponsorship, strategicalliances, and/or cross-institutional collaboration. Public sharing canutilize social media and/or publishing as a resource to anorganization's branded platform, which can be leveraged by and forinstitutional use, such as industry sponsorships, strategic alliances,cross-discipline research, program recruitment, and/or media-richlearning.

Some embodiments can be implemented as single platforms for workflow andcommunications. Such platforms can reduce transaction costs associatedwith multiple legacy technologies and administrative workload.Administrators can set user-permissions and create a secure environmentfor users to virtually collaborate without admin or IT assistance. Thiscan foster cross-institutional research, commercialization, andmulti-institutional projects. The platform can include a crowd-sourceddatabase to further reduce costs associated with developing andmaintaining a digital library of stakeholders, research, andinstitutional resources.

The platform can amplify a group's messaging by, e.g., aggregating itscombined resources. The decentralization of tasking and responsibilitiescan provide transparent workflow for simplified administrative oversightand peer or team review of research, proposals, due-diligence,documentation, and/or ongoing reporting. Secure file transfer coupledwith database technology can negate expensive legacy products andexternal vendors, and can be adapted for marketing solutions or ad hocproduct suites, which otherwise could violate IP transfer securityprotocols.

Embodiments can include multiple channels, built in search engineoptimization (SEO), media capabilities, and/or visual Web 2.0. These canimprove engagement through search ranking, content tagging, and/orintuitive discovery interfaces. For example, stakeholders, users,researchers, etc. of an institution can build digital career portfolioswith CVs, social links, media, digital files, and/or web links. Profilescan also be searchable by various criteria, such as organization,skills, and/or areas of interest, facilitating stakeholders' connectionsthrough the platform or via links to profiles on Facebook, LinkedIn,Twitter, or other social media. Potential financial stakeholders orother interested parties can search all published public content as wellas non-public content that such persons have permission to view. Theplatform can also allow following of an individual or body of work.Users can also have a multi-media platform to respond to current eventsor public questions in a comprehensive, contextualized format. Datafeeds from media outlets, such as government sites, can be served via anAPI. Such feeds can be viewed and/or followed through the platform.

Embodiments can reduce administrative bottlenecks and decentralizeworkloads. Moreover, they can be implemented with user-friendly and/orintuitive graphical user interfaces (GUI) such that social tools neednot require technical expertise, increasing stakeholder participation.Through permissions granted by an administrator, authorized users canmanage their own content and/or projects, invite collaborators, makeconnections, network, and/or amplify messaging. A directory can beutilized, which can allow public users to locate other users, such asresearchers or start-up entrepreneurs, in order to connect with themand/or follow their work. Organizations can leverage publishedstakeholder content for, e.g., marketing, education, and/or increasedaccess to resources.

Embodiments can include various core features, such as administrativecontrols, decentralized functionality, curation, social business tools,access & sharing, metadata & SEO, and/or search & follow. Administratorscan control page branding, user permissions (e.g. editor approval beforepublishing), and/or public organizational/departmental pages. Eachauthorized user can maintain his or her user account. User accountlimits (e.g. for sharing and/or collaboration), properties, andfunctionality can be set by administrators. A user can upload files andcollect content into curations, i.e. multi-source, multi-media folders,which can be linked to the user's profile. Users can also create slidepresentations, connect through chat or organizational email, and/orcreate virtual work spaces for multiple, decentralized collaborators. Ina preferred embodiment, all content can be saved as private, and usersand/or administrators can permit selective access (e.g. for filetransfer and/or collaboration) or publish, such as to a social medium.Metadata can be edited by the content owner or uploader, such as bymeans of clickable buttons on a GUI, and can be optimized for searching.Users can publish curations for potential stakeholders or otherinterested parties to search and/or follow.

Embodiments can also include various customizations, such as to enhancesecurity, searching, publishing, and/or analytics. For example,embodiments can incorporate one or more of the security protocolsdescribed herein and/or as are known in the art. Customization canfurther include user interfaces having customized search fields,categories, and/or content mapping.

FIGS. 10 and 11 depict aspects of exemplary activation process andneighborhood identification. In a first step, shown in FIG. 10, a systemadmin request can be made for an activation code by filling in a formfrom a proprietary website and/or an intranet location. Form inputs caninclude a unique identifier, such as a media access control address (MACaddress), the number of seats, an IP address, and neighborhood details.In a second step, as shown in FIG. 11, an admin can validate the inputgiven by a user and generate an activation code. The activation code canbe a unique, random string. After installing the application, the systemadmin can feed the activation code and activate the application. A PAScan validate the MAC address of the system where the application isinstalled and the number of seats. In a third step, a neighborhood IDcan be generated. Once the activation code is activated successfully, aneighborhood ID will be generated by the PAS and sent to theapplication. The neighborhood ID can be a unique random alpha numericstring (e.g. 16 char). Each neighborhood ID can be mapped by MACaddress, number of seats, IP address, and/or activated timestamp. TheMAC address can be encrypted and stored as encrypted text or as a hashvalue on the database. The system can also utilize PeerID, which can bea unique random alpha numeric string (e.g. 16 char). Each PeerID can bemapped by neighborhood ID, IP address, PeerID generated timestamp,and/or browser details such as browser name, user agent, HTTP_ACCEPTheader, browser plugin details, time zone, screen size and color depth,system fonts, and/or cookies. Brower and system details can be stored byPeerID, for example, to validate whether a user uses the same system foreach instance.

Other embodiments are within the scope of the following claims.

1. A secure network ecosystem, comprising: a URL programming interface;a server configured to receive a request from the URL programminginterface, wherein the server includes a file manager, an authenticationserver, a resource server, and a collaboration server; and a securedatabase connected to the server.
 2. The system of claim 1, wherein theauthentication server ensures that the request is valid.
 3. The systemof claim 1, further comprising an application program interfaceconfigured to authenticate a token generated by the authenticationserver.
 4. The system of claim 3, wherein the request is an HTTPcommunication.
 5. The system of claim 3, wherein the request is an FTPcommunication.
 6. The system of claim 1, further comprising a secondsecure network ecosystem, wherein the second secure network ecosystemcomprises: a second URL programming interface; a second server; and asecond secure database connected to the second server; wherein thesecond secure network ecosystem is configured to receive the request andan authentication request from the secure network ecosystem.
 7. Thesystem of claim 6, wherein the second server determines whether therequest is authorized based on a token generated by the authenticationserver.
 8. The system of claim 3, wherein the token has a lifetime ofless than five minutes.
 9. The system of claim 8, wherein the token hasa lifetime of less than two minutes.
 10. The system of claim 1, whereinthe resource server includes a central repository of metadata.
 11. Thesystem of claim 10, wherein the metadata is publicly available.
 12. Thesystem of claim 11, wherein the metadata is associated with content, andwherein the content is not publicly available.
 13. The system of claim12, wherein filenames associated with the content is not publiclyvisible.
 14. The system of claim 11, wherein the metadata is publiclysearchable.
 15. The system of claim 10, wherein the resource serverincludes a token validator, a query engine, and a metadata manager. 16.The system of claim 1, wherein data is stored on the secure database ina first normal form (1NF).
 17. The system of claim 16, wherein the dataviolates a third normal form (3NF).
 18. The system of claim 1, whereinthe secure database is at least partially non-normalized.
 19. The systemof claim 18, wherein the secure database contains content, and whereinfilenames associated with the content are encrypted.
 20. The system ofclaim 19, wherein extensions associated with the content are encrypted.21.-25. (canceled)